<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="content-type">
  <title>Makumba Design</title>
  <link rel="stylesheet" type="text/css" media="all" href="noMenu.css">
</head>
<body>
<h1>Makumba design</h1>
<br>
Intro<br>
<ul>
  <li><a href="#SOP">Statement of purpose</a></li>
  <li><a href="#issue_design">The issue of design</a></li>
  <li><a href="#design_objectives">Objectives of design work</a></li>
  <li><a href="#3rd_party">3rd party technologies</a></li>
</ul>
Makumba components and design status<br>
<ul>
  <li><a href="#maklist">The mak:list engine</a></li>
  <li><a href="#makform">Forms</a></li>
  <li><a href="#mdd">MDD</a></li>
  <li><a href="#database">Database layer</a></li>
  <li><a href="#oql">OQL</a></li>
  <li><a href="#login">Login/Access control<br>
    </a></li>
  <li><a href="#BL">Business logic</a><br>
  </li>
  <li><a href="#controller">Controller</a> </li>
  <li><a href="#templates">Templates</a></li>
  <li><a href="#developer">Developer tools and documentation</a></li>
  <li><a href="#arhitecture">Internal architecture</a></li>
</ul>
<a href="#tech_today">Technologies used by makumba today and their
versions<br>
</a>
<h2><a href="#tech_today" name="SOP"></a>Statement of purpose </h2>
<p><font size="-1">(Should be put in sentences and posted on
www.makumba.org. See also the <a href="whitepaper.html">whitepaper</a>.
The previous review of makumba design dates from 2000, <a
 href="makumba.html">look at it</a> to get more historical context)</font><br>
</p>
<h3>What do we design Makumba for?</h3>
<ul>
  <li>fast member involvement</li>
  <li>rapid development</li>
  <li>based on members' <a href="#links_html" class="simplelink">HTML</a>
and <a href="#links_sql" class="simplelink">SQL</a> knowledge</li>
  <li>unlike popular scripting languages, it still enforces a clean
model-view-controller (<a href="#links_mvc" class="simplelink">MVC</a>)
architecture, leading to a healthy structure of the applications even
as members come and go</li>
  <li>db-driven web applications (clear delimitation of the technology)</li>
  <li>simple (few concepts)</li>
  <li>source code should be clear and easy readable to ensure efficient
learning by example for new members<br>
  </li>
  <li>easy to install (few commands/directories/files to work with)</li>
  <li>independent of any commercial technology or data format (easy to
migrate to other technologies that can access databases through <a
 href="#links_sql" class="simplelink">SQL</a>)<br>
  </li>
  <li>as much as possible "compiled" rather than interpreted (tell the
developer at first page execution that somthing is rotten, rather than
wait for it to blow in production)<br>
  </li>
  <li>personal member development towards <a href="#links_java"
 class="simplelink">Java</a>, <a href="#links_mvc" class="simplelink">MVC</a>,
    <a href="#links_http" class="simplelink">http</a>, <a
 href="#links_jsp" class="simplelink">JSP</a> and
other technologies involved<br>
  </li>
</ul>
<h2><a name="issue_design"></a>The issue of design</h2>
The biggest issue with Makumba today is design. <br>
Reasons:<br>
<ul>
  <li>design is originality: if Makumba design weren't original, there
would be no need for Makumba, sth else could be used<br>
  </li>
  <li>there was a lot of pressure to stop design and start
implementation, so some parts of Makumba are still poorly designed
(while others give its strength and originality)<br>
  </li>
  <li>a lot of stuff had to be implemented from scratch as the standard
or 3rd party technologies at the time (1999-2001) were non-existent, in
bad shape, or uncertain. Even the ubiquitous <a href="#links_tomcat"
 class="simplelink">Tomcat</a> did not exist at
the time, and <a href="#links_jsp" class="simplelink">JSP</a> was in
its conceiving stages</li>
</ul>
<h2><a name="design_objectives"></a>Objectives of Makumba design work</h2>
We should adjust the Makumba design so that:<br>
<ul>
  <li>keeps its strength and originality as expressed in the statement
of purpose above</li>
  <li>makes better use of 3rd party technology (especially
java-endorsed standards), taking advantage of their healthy design,
reliability and 'standardness'. <br>
  </li>
  <li>in components where Makumba is still considered more original, or
3rd party technologies are still unsatisfactory, publish the respective
part of Makumba as a separate, original product</li>
  <li>this will lead to a smaller, easier to maintain, and more
reliable Makumba. <br>
  </li>
  <li>eliminating sluggish design will make us more proud and ready to
better promote Makumba in the open-source world</li>
</ul>
As such, what we need to do now, is search literature and read, not
write code, except where design is straight-forward and experience from
Karamba and other applications clearly shows that a feature is needed,
and can't wait much for redesign.<br>
<span style="font-weight: bold;"></span>
<h2><a name="3rd_party"></a>3rd party technologies</h2>
<h3><span style="font-weight: bold;"></span>how to look at a technology:</h3>
<ul>
  <li>is it used by Makumba already? If so, does Makumba use it to its
full potential (e.g. it may be that Makumba adopted the technology
early in its development)</li>
  <li>if not, what would it do for Makumba, in which area?</li>
  <li>try out the technology. Install it and do an example <br>
  </li>
  <li>is it a standard? Would it be good for BEST members' personal
development to learn it?<br>
  </li>
  <li>would the overhead (in installation/configuration, data
conversion, etc) of using that technology be acceptable? Would the
development process (Makumba usage) be easier? Even if it would be a
bit more difficult, are the other advantages important enough?<br>
  </li>
  <li>in general, how will Makumba+that technology respect the
statement of purpose?</li>
</ul>
See also <a href="#tech_today">technlogies used by Makumba today</a>
<p></p>
<h1>Makumba components and their design status</h1>
<font size="-1">For reference on each component, see a <a
 href="hacking/index.html">detailed description</a> of Makumba
internals. See also <a href="http://bugs.best.eu.org">bugzilla</a>
especially the makumba target versions 0.6 and 0.7</font>
<h2><a name="maklist"></a>mak:list engine</h2>
<h3>design status:</h3>
<ul>
  <li>Lately we call this "query fragments".<span
 style="font-family: monospace;"></span> This is clearly the most
original and
powerful part of Makumba.</li>
  <li>familiarity with <a href="#links_sql" class="simplelink">SQL</a>
within <a href="#links_html" class="simplelink">HTML</a> is well
encouraged. Groups of
mak:lists are nicely combined in a high-performance original way</li>
  <li>$attributes are transformed into $1 <a href="#links_oql"
 class="simplelink">OQL</a> attributes in an easy
transparent manner</li>
  <li>easy nesting of mak:lists and composing queries from them. This
seems to be very original to Makumba</li>
  <li>number of queries generated is independent on the number of
results of any enclosing mak:list.&nbsp; This is the crux to makumba
performace.</li>
  <li>recently there are ideas of displaying data from a generic
database, e.g. from an XML file</li>
</ul>
<h3>design still not finished for</h3>
<ul>
</ul>
<ul>
  <li>the query-fragments concept is currently used only in the view
level. A the last meeting we started to experiment with using it at the
BL level for authentication, but also more use at view level for e.g.
not showing inaccessible links. using query-fragments for both BL and
view would allow the query engine to optimize its queries much better
so e.g. the number of queries per access would be minimal. this is a
cool design challenge (and if we can get it right, it can become yet
another makumba strong point, along with the existing three).</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=63">search</a>.
There is little support for search forms and their response (which will
include mak:lists)&nbsp; although mak:list query fragments are pretty
flexible now</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=25">counting</a>&nbsp;
(25)<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=572">default
value</a>&nbsp; (should it be constant or OQL?)</li>
  <li>mak:value() as a EL function ${mak:value("someOQLExpr") }</li>
  <li>text type formatting: there seems to be confusion around
html=auto, <a href="http://bugs.best.eu.org/show_bug.cgi?id=440">html=true</a>,
maxlinelength, <a href="http://bugs.best.eu.org/show_bug.cgi?id=38">problems
with line separators</a>,&nbsp; etc</li>
  <li><span style="color: rgb(153, 0, 0);">paging</span><br>
  </li>
</ul>
<h3>implementation status:</h3>
<ul>
  <li>the <a href="#links_jsp" class="simplelink">JSP taglib API</a>
is still not enough
for Makumba's needs. Makumba-specific JSP page parsing needed to be
introduced in the latest taglib version.</li>
  <li>there are small features missing but the new architecture of <a
 href="http://www.makumba.org/hacking/javadoc/org/makumba/view/jsptaglib/package-summary.html">org.makumba.view.jsptaglib</a>
allows for easy extensions<br>
  </li>
  <li> <a href="http://bugs.best.eu.org/show_bug.cgi?id=713">distinct</a>
is still needed for lists. </li>
  <li>the current implementation/architecture is <a
 href="http://www.makumba.org/hacking/javadoc/org/makumba/view/jsptaglib/package-summary.html#package_description">pretty
complex</a> (see a <a href="Terms-org.makumba.view.jsptaglib.doc">diagram</a>).
Maybe <a href="#links_jsp" class="simplelink">JSP</a> design should be
actively lobbied at the Java Community Process (JCP)? Or should the
ambitions be
reduced? Maybe more research on <a href="#links_jsp2.0"
 class="simplelink">JSP 2.0</a> (especially "simple tags") can
help solving this?</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=806">automatic
$parameter conversion from string to int</a></li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=54">server
hangup by wrong queries</a> </li>
</ul>
<h3>3rd-party tools and standards:</h3>
<ul>
  <li>of course many tag libraries (incl the
standard <a href="#links_jstl" class="simplelink">JSTL</a>) know how
to do <a href="#links_sql" class="simplelink">SQL</a> queries or
display
tables (<a href="#links_jsf" class="simplelink">JSF</a>) but none
combine the two like
mak:list does (for better or worse)</li>
  <li>the taglib was designed for JSP 1.1, since then JSP 1.2 and
especially <a href="#links_jsp2.0" class="simplelink">2.0</a> added
more
features that, integrated in Makumba, may simplify
Makumba pages. We already use some 2.0 features, such as taglib
functions for mak:count() etc.</li>
  <li>especially the Expression Language (EL) of <a
 href="#links_jsp2.0" class="simplelink">JSP 2.0</a> makes it much
easier to display values by using ${expression } notation</li>
  <li><a href="#links_jstl" class="simplelink">JSTL</a> helps <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=65#c6">replace java
scriptlets</a>. Makumba should be integrated
more with it<br>
  </li>
</ul>
<h2><a name="makform"></a><a href="makumba-spec.html#forms">forms</a></h2>
<h3>design status:</h3>
<ul>
  <li>think for example that you could use forms to build e.g. java
objects instead of makumba ones:<br>
* say you have a separate taglib with prefix "form", then you write
&lt;form:new type="mypackage.myType" ...&gt; i.e. you indicate a Java
type instead of a Makumba one. most of the current mak:form philosophy
would stay the same, but the concept would be more general. with the
same tags you would be able to create mak:objects and (e.g.) java
objects.<br>
* in other words the (increasingly powerful) form engine does not have
to be tied to makumba databases. i also think viewing them separately
will lead to a much better structure by reducing dependencies between
them. this is not very far, the current structure is pretty healthy in
this respect.</li>
  <li>keep nice familiarity with <a href="#links_html"
 class="simplelink">HTML</a>, while
taking good advantage of the MDD information. This is a strength of
Makumba design</li>
  <li><a href="makumba-spec.html#forms">multiple forms</a> are powerful
and original. You can use any number of forms inside of a form, enclose
forms in mak:lists, etc</li>
</ul>
<h3>design still not finished for</h3>
<ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=281">form
annotations</a></li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=417">expanding
form interaction over more pages</a> (wizard)<a
 href="http://bugs.best.eu.org/show_bug.cgi?id=417"><br>
    </a></li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=783">extra fields</a>
(783)<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=781">autoforms</a>
(781)</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=784">non-ptr
non-set options </a>(784)<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=501">defaultValue</a>
(501) not clear whether it should be OQL or constant expr<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=796">empty forms
as links</a> (796), <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=16">delete as button</a>
(16)<a href="http://bugs.best.eu.org/show_bug.cgi?id=16"><br>
    </a></li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=685">guards that
enable forms</a> (685)<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=510">date input
control</a> needs improvement (510)</li>
</ul>
<div style="margin-left: 40px;"></div>
<h3>implementation status</h3>
<ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=190">multiple
submission</a> of new and add forms should be detected</li>
  <ul>
    <li><span style="color: rgb(204, 0, 0);">hide the button on click
via javascript (won't solve refresh)</span><br>
    </li>
  </ul>
  <li>see unfinished design above</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=790">show
form/input whose response fails</a> (790)</li>
  <li>multiple forms: <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=687">use a result in a
field of a subsequent form</a>&nbsp;
(687)</li>
  <li>mak:attribute (somewhat connected to forms) and findXXX methods <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=787">should be deprecated</a>&nbsp;
(787)<br>
  </li>
  <li>form responders are <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=363">lost</a> at webapp
reload. The user needs to go back and resubmit the form if the webapp
is reloaded while they submit it.</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=809">the page
analyzer should understand jsp:attribute</a>, especially for mak:action</li>
  <li>set editors should offer a<a
 href="http://bugs.best.eu.org/show_bug.cgi?id=822"> two-choser</a>
variant</li>
  <li>set int{} <a href="http://bugs.best.eu.org/show_bug.cgi?id=788">should
allow submitting empty sets</a> (788)</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=585">checkbox/radio
button options </a>still not closed (585)<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=797">mak:option
fails with subrecords</a> (797)<br>
  </li>
</ul>
<h3>3rd-party tools and standards</h3>
<ul>
  <li><a href="#links_jsf" class="simplelink">JSF</a> has excellent
design towards transforming web interaction into component-based
interaction. However, that goes too far into breaking the familiarity
with HTML forms, while bringing in a much less spread familiarity (GUI
component programming)<br>
  </li>
</ul>
<h2><span style="font-weight: bold;"><a name="mdd"></a>MDD (data model)</span></h2>
<h3>design status</h3>
<ul>
  <li>a simple, easy to read,
database-neutral data description.</li>
  <li>a small number of types, that cover
most needs. More types would bring better performance, but create more
confusion</li>
  <li>some concepts could have better names (more related to db
theory): set,
internal set/pointer, etc<br>
  </li>
</ul>
<h3>design still not finished for</h3>
<ul>
  <li><span style="font-weight: bold;">a cleaner MVC was discussed at
the
first congress.&nbsp; Basically a part of the BL should be integrated
with
the MDDs (and remain as model), and another part should stay close (and
maybe be integrated more) with the JSPs and be part of the controller</span></li>
  <li>May be dropped or adapted for simple java classes and
EJB/Hibernate<span style="font-weight: bold;">.</span><br>
  </li>
</ul>
<br>
<ul>
  <li>the initial ambition was to be
object-oriented: encapsulation is more or less done, but inheritance
and polymorphism are still not addressed. Is this really needed?</li>
  <li><span style="color: rgb(153, 0, 0);">subtyping</span> (a database
theory concept) is supported but can be
made more
explicit</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=7">business rules</a>
(see also <a href="http://bugs.best.eu.org/show_bug.cgi?id=234">business
objects</a>). A data model should not only describe data, but
also specify rules on how it can be created and changed</li>
  <ul>
    <li><span style="color: rgb(153, 0, 0);">session objects,&nbsp;
caching, dirty caching</span><br>
    </li>
  </ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=832">bidirectional
sets</a> is a new idea. Easy to implement, may still need a bit of MDD
language design<br>
  </li>
</ul>
<h3>implementation status</h3>
<ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=811">inheritance</a>
(811) is pretty well planned<br>
  </li>
  <li>the parser is a bit messy but it works</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=513">multiple-field
uniqueness</a> still not done<br>
  </li>
</ul>
<h3>3rd-party tools and standards</h3>
<ul>
  <li>there is acute need for database theory
reading (to decide whether to have it object-oriented or keep it
relational, etc)</li>
  <li><a href="#links_jdo" class="simplelink">JDO</a> supports (in Java
standard, there are other tools like
it) an object-oriented way to describe data and deal with it, and make
objects
persistent<br>
  </li>
</ul>
<h2><span style="font-weight: bold;"><a name="database"></a>Database
layer</span></h2>
<h3>design status</h3>
<ul>
  <li>a pretty straightforward API for accessing MDD-generated tables
in a database-neutral manner</li>
  <li>maybe Database should be really called Transaction, or Connection.</li>
  <li>maps MDDs to DB tables. When reading a non-Makumba DB this is
especially useful</li>
  <li>maps Makumba types on their best representation in the host DB
engine</li>
  <li>the API for sending arguments to queries and updates and for
retrieving query results using java.util.Dictionary seems to be pretty
heavy. Besides, it is not type-safe.<br>
  </li>
</ul>
<h3>design still not finished for</h3>
<ul>
  <li>uncertainty about object-orientation (see MDD) <br>
  </li>
  <li>case insensitivity is not provided <br>
  </li>
</ul>
<h3>implementation status</h3>
<ul>
  <li>old, trusted code, using <a href="#links_jdbc" class="simplelink">JDBC</a>
1</li>
  <li>there is a <a href="http://bugs.best.eu.org/show_bug.cgi?id=580">discussion</a>
on whether to use foreign keys or not</li>
  <li>presently indexes are created for almost every field. This
results in
the <a href="#links_sql" class="simplelink">SQL</a> engine <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=671">not knowing which
to use</a></li>
  <ul>
    <li><span style="color: rgb(153, 0, 0);">maybe do the indexes only
for foreign keys and some selected fields</span><br>
    </li>
  </ul>
  <li>timestamps should be <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=765">created in the db
server<br>
    </a></li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=815">Error when
no DBSV is specified</a></li>
  <li><span style="color: rgb(153, 0, 0);">subrecord TS_modify update</span><br>
  </li>
</ul>
<h3>3rd-party tools and standards</h3>
<ul>
  <li>database-neutrality made lots of
progress in the past years. <a href="#links_jdo" class="simplelink">JDO</a>,
    <a href="#links_jdbcConnector" class="simplelink">JDBC Connector</a>,
even <a href="#links_jdbc" class="simplelink">JDBC</a> itself
do much better then they used to. Dropping the db layer for one of
these technologies could be very beneficial</li>
  <li>the <a href="#links_jdbc" class="simplelink">JDBC API</a>
(currently at version 3 and going towards version 4)
made
lots of progress since JDBC 1, most probably there are loads of
features that Makumba does not take advantage of, including e.g. Rowsets<span
 style="font-weight: bold;"><br>
    </span></li>
</ul>
<h2><span style="font-weight: bold;"><a name="oql"></a><a
 href="#links_oql" class="simplelink">OQL</a> </span><span
 style="font-weight: bold;">
(object query language)</span></h2>
<h3>design status</h3>
<ul>
  <li>May be dropped for EJB QL or Hibernate QL<br>
  </li>
  <li>specify queries in a database-neutral
manner. But this can increasingly be done in simple, standard <a
 href="#links_sql" class="simplelink">SQL</a>.</li>
  <li><a href="#links_oql" class="simplelink">OQL</a> is also used to
translate from MDD names to DB table names in
queries (by calling the DB layer)</li>
  <li>we borrowed <a href="#links_oql" class="simplelink">OQL</a>
from the now defunct <a href="#links_odmg" class="simplelink">ODMG</a>.
The initial version of their <a href="#links_oql" class="simplelink">OQL</a>
grammar is <a
 href="http://cvs.best.eu.org/cgi-bin/cvsweb.cgi/makumba/classes/org/makumba/db/sql/oql/OQL-fixed.G">still
on the Makumba CVS</a>. </li>
  <li>the ambition was to be object-oriented (see MDD)</li>
  <li>an important feature of Makumba <a href="#links_oql"
 class="simplelink">OQL</a> that distinguishes it from <a
 href="#links_sql" class="simplelink">SQL</a> is
the ability to refer sets easily <br>
    <code>FROM general.Person p, p.addresses a</code> <br>
instead of<br>
    <code>FROM general.Person p, general.Person-&gt;addresses a
WHERE a.person=p</code><br>
though the second form should also work</li>
  <li>another important feature is the ability to analyze queries,
including
type checking, useful during page analysis. Even if we adopt a thrid
party technology or simply decide to use SQL, some form of query
parsing will still be needed.<br>
  </li>
</ul>
<h3>design still not finished for</h3>
<ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=26">functions</a>.
They should probably keep
the object oriented manner (object.call(arguments) )</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=263">comparisons
with current date</a></li>
</ul>
<h3>implementation status</h3>
<ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=821">set
selection in original order</a> is a new idea, rather nice to provide<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=27">subqueries</a>
are badly missed</li>
  <li>patchy, hard to add new features. One should probably start fresh
from the <a
 href="http://cvs.best.eu.org/cgi-bin/cvsweb.cgi/makumba/classes/org/makumba/db/sql/oql/OQL-fixed.G">original
OQL grammar</a> and reimplement it to add functions and subqueries</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=748">date
arithmethic</a>, a new idea<br>
  </li>
</ul>
<h3>3rd-party tools and standards</h3>
<ul>
  <li>database-neutrality made lots of
progress in the past years. <a href="#links_jdo" class="simplelink">JDO</a>
(which has its own form of OQL), <a href="#links_jdbcConnector"
 class="simplelink">JDBC Connector</a>, even <a href="#links_jdbc"
 class="simplelink">JDBC</a> itself do
much better then they used to. Dropping or adapting <a
 href="#links_oql" class="simplelink">OQL</a> for one of
these
technologies could be very beneficial. JDO is explicitely recommended
by <a href="#links_odmg" class="simplelink">ODMG</a> as the natural
place to go<br>
  </li>
</ul>
<h2><a name="login"></a>Login/Access control<br>
</h2>
<h3>design status</h3>
<ul>
  <li>based on "secret attributes". The design was so poor that it had
to be patched with
"checkAttributes".</li>
  <ul>
    <li><span style="color: rgb(204, 0, 0);">secret attribute $x in JSP
less used</span><br>
    </li>
  </ul>
  <li><span style="color: rgb(204, 0, 0);">bad support for
authorization, separation of authorization logic</span></li>
  <li><span style="color: rgb(204, 0, 0);">knowing the rights of the
user in the view</span></li>
  <li><span style="color: rgb(204, 0, 0);">acegisecurity.sourceforge.net<br>
    </span></li>
  <li>the design led to a number of problems, including secret
attributes
with identical names in different parts of the site</li>
  <li>the design also hides the concept of session, which is important
to
learn (and use) for developers. Sessions can be used for more than login</li>
  <li> there is limited support for the <a href="#links_servlet"
 class="simplelink">servlet specification</a> standard login. If R is a
role and the user is in that role, then $R will evaluate to the user
name.</li>
  <li>there were design discussions about roles, &lt;mak:checkRole&gt;.
Also this could allow to show some content (links) only if the user has
the right to see them.</li>
  <li>how to deal with replicas? Database replicas should be encoded,
otherwise the replica administrator can see everything. Even so, the
JSP writer should not have the right to execute just any query! There
was an idea based on "tickets" to limit that.<br>
  </li>
</ul>
<h3>3rd-party tools and standards</h3>
<ul>
  <li>the <a href="#links_servlet" class="simplelink">servlet
speficification</a> itself has a
good login design, and that standard login (and the design of its
integration in Makumba) should be looked at more</li>
  <li>there are other tools like <a href="#links_jsai"
 class="simplelink">jSai</a> that seem to work in this
department</li>
</ul>
<h2><a name="BL"></a>"Business Logic"</h2>
<h3>design status</h3>
<ul>
  <li>bad design, <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=7#c6">mixture between
logic and
controller.</a></li>
  <li>thus the "clean <a href="#links_mvc" class="simplelink">MVC</a>"
part of the statement of purpose is still
not well
addressed</li>
  <li>it's clear that business rules should live with the data, maybe
in MDD
files, maybe near them. Currently they tend to follow the JSP page
structure rather than the MDD structure</li>
  <li>parts that are more dependent on the interface (on the way the
form was
shown, etc) should be part of the controller</li>
  <li><span style="color: rgb(204, 0, 0);">non-java BL</span><br>
  </li>
</ul>
<h3>design still not finished for</h3>
<ul>
  <li>maybe this part should be completely
restructured.</li>
  <li>stuff that does pure data processing should move to "data model"</li>
  <li>stuff that does data adaptation from and to the dialogs (forms)
should
go to the controller</li>
  <li>sessions should be visible to the model, the controller, or both <br>
  </li>
</ul>
<h3>3rd-party tools</h3>
<ul>
  <li>Jakarta <a href="#links_struts" class="simplelink">Struts</a>, <a
 href="#links_jsf" class="simplelink">JSF</a>, <a href="#links_ejb"
 class="simplelink">EJB</a> (e.g. for
session design)</li>
</ul>
<h2><a name="controller"></a>Controller</h2>
<h3>design status:</h3>
<ul>
  <li>transparent for now. Executes at every
page access, via a servlet filter</li>
</ul>
<h3>design still not finished for:</h3>
<ul>
  <li>see "business logic" above: stuff
that's
specific to the form <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=7#c6">should be
specified in/near the JSP</a> and executed
by the controller</li>
  <li>not able to show different pages after form submission ("view
selection", bugs <a href="http://bugs.best.eu.org/show_bug.cgi?id=29">29</a>,
    <a href="http://bugs.best.eu.org/show_bug.cgi?id=443">443</a>)</li>
  <li>in general, not enough flexibility in treating the errors</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=800">attribute
debugging</a> (800)</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=617">after_add
doesn't have access to base pointer</a> (617)<a
 href="http://bugs.best.eu.org/show_bug.cgi?id=617"><br>
    </a></li>
</ul>
<h3>3rd-party tools:</h3>
<ul>
  <li>Jakarta <a href="#links_struts" class="simplelink">Struts</a>, <a
 href="#links_jsf" class="simplelink">JSF</a><br>
  </li>
</ul>
<h2><a name="templates"></a>Templates/Components<br>
</h2>
<h3>design status:</h3>
<ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=68">none done</a><br>
  </li>
  <li>templating was really desired from the <a href="makumba.html">very
begining</a> of Makumba.</li>
  <li>it becomes more and more important as it seems that "dynamic
website components" become pretty important on the net today, e.g. in <a
 href="#links_cms" class="simplelink">CMS</a> systems</li>
  <li>included mechanisms can be a way to support templates. The
current support for include mechanisms (jsp:include and @include) do
not cross mak:list contexts. You can't have a mak:list and include
something within it which would</li>
  <ul>
    <li>be dynamic in name (i.e. decide what to include at runtime)</li>
    <li>know its context (i.e. know that it's included in a certain
type of mak:list)</li>
  </ul>
  <li><a href="#links_jsp2.0" class="simplelink">JSP 2.0</a> supports
the definition of new tags in JSP files (tag
files) instead of Java classes. This can also support templating</li>
  <ul>
    <li style="color: rgb(204, 0, 0);">Jakarta Tiles</li>
    <li><span style="color: rgb(204, 0, 0);">OpenSymphony SiteMesh</span><br>
    </li>
  </ul>
</ul>
<h3>3rd-party tools</h3>
<ul>
  <li><a href="#links_jsp2.0" class="simplelink">JSP 2.0 tag files</a></li>
  <li><a href="#links_phpnuke" class="simplelink">PHPNuke</a> as an
example</li>
</ul>
<h2><a name="developer"></a>Developer tools &amp; Documentation<br>
</h2>
(the jspx, mdd viewers, <a href="#links_ant" class="simplelink">Ant</a>
files like commons.xml, etc)
<h3>design status:</h3>
<ul>
  <li>pretty original, building on the
originality of MDD and JSP parts<br>
  </li>
</ul>
<h3>design still not finished for:</h3>
<ul>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=39">interacting
more with the
programmer</a> during development</li>
  <li><span style="color: rgb(204, 0, 0);">more Eclipse tools (MDD
plugin)</span></li>
  <li><span style="color: rgb(204, 0, 0);">Parade editors</span></li>
</ul>
<h3>implementation status:</h3>
<ul>
  <li><span style="color: rgb(204, 0, 0);">API documentation</span></li>
  <li><span style="color: rgb(204, 0, 0);">Mak specification is too big</span></li>
  <li><span style="color: rgb(204, 0, 0);">Confluence with Bugzilla<br>
    </span></li>
  <li><span style="color: rgb(204, 0, 0);"></span><a
 href="http://bugs.best.eu.org/show_bug.cgi?id=814">expand
includes in JSP source viewer</a> (814)<br>
  </li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=782">"pages and
BL classes affected by an MDD"</a> (782) still not implemented,
although most of the tools are in place (page analysis, etc) <br>
  </li>
  <li>splitting specification into more documents</li>
  <li><a href="http://bugs.best.eu.org/show_bug.cgi?id=816">linking to
lines of sources rather than just to the file (816)</a></li>
</ul>
<h3>3rd-party tools</h3>
<ul>
  <li><a href="#links_ant" class="simplelink">Ant</a></li>
  <li><a href="#links_eclipse" class="simplelink">Eclipse</a></li>
</ul>
<h2><a name="arhitecture"></a>Internal architecture design</h2>
<font size="-1">For reference on the internal design, see a <a
 href="hacking/index.html">detailed description</a> of Makumba
internals.</font>
<h3>design status:</h3>
<ul>
  <li>this is not a very important part of design (is not affecting the
user) but it is important for sustaining Makumba</li>
  <li>handler families seem to be problematic to understand and maintain</li>
  <li>there are automatic tests for the most critical part (database
layer) and for others (MDD, etc) but they are badly missed for the
taglib.<br>
  </li>
</ul>
<h3>design still not finished for:</h3>
<ul>
  <li>we were not sure how <a
 href="http://bugs.best.eu.org/show_bug.cgi?id=111">handler families
could be redesigned</a> but now we got around that<a
 href="http://bugs.best.eu.org/show_bug.cgi?id=111"><br>
    </a></li>
</ul>
<h3>&nbsp; implementation status:</h3>
<h3>3rd-party tools</h3>
<ul>
  <li>Jakarta <a href="#links_cactus" class="simplelink">Cactus</a>
can help in making automatic tests for the Makumba JSP taglib layer</li>
  <li><a href="#links_eclipse" class="simplelink">Eclipse</a> can help
refactoring<br>
  </li>
</ul>
<h2><a name="tech_today">technologies used by Makumba today, and their
versions</a></h2>
<ul>
  <a name="tech_today"> <li><br>
  </li>
  </a><a href="#links_java" class="simplelink">Java</a> of course. The
latest 1.5 version brings a lot of useful
stuff, e.g. for business logic code (e.g. using int and Integer
interchangeably i.e. autoboxing) <li><a href="#links_jsp"
 class="simplelink">JSP</a>: used to implement the taglib. Mostly 1.1
is used (though <a href="#links_jsp2.0" class="simplelink">JSP 2.0</a>
brings lots of useful stuff for the Makumba user)</li>
  <li><a href="#links_servlet" class="simplelink">servlet</a>: used to
filter requests (the mak controller), display
errors, etc. Servlet 2.2 was not supporting filters, we introduced that
with servlet 2.3<br>
  </li>
</ul>
<h3>technologies transparent for the Makumba programmer</h3>
<ul>
  <li><a href="#links_antlr" class="simplelink">ANTLR</a>: used to
parse OQL. We
went through antlr 2.7.1 and 2.7.2. only 2.7.2 works with <a
 href="#links_jikes" class="simplelink">Jikes</a> 1.18
(see below)<br>
  </li>
  <li><a href="#links_junit" class="simplelink">Junit</a>: used to test
Makumba</li>
  <li>both <a href="#links_jsp" class="simplelink">JSP</a> and <a
 href="#links_servlet" class="simplelink">servlet</a> need a servlet
container, we use <a href="#links_tomcat" class="simplelink">Tomcat</a>
for
that. It's not always transparent for users. We went through Tomcat 3,
4 and 4.1. Tomcat 5 is now up, supporting <a href="#links_jsp2.0"
 class="simplelink">JSP 2.0</a> and <a href="#links_servlet"
 class="simplelink">servlet 2.4</a></li>
  <ul>
    <li><a href="#links_jasper" class="simplelink">Jasper</a> (the <a
 href="#links_jsp" class="simplelink">JSP</a> compiler) is an important
part of <a href="#links_tomcat" class="simplelink">Tomcat</a>.
Jasper 2 was introduced with Tomcat 4.1. </li>
    <li><a href="#links_jikes" class="simplelink">Jikes</a> is a fast
java compiler, used to compile Java code
generated by Jasper (and to compile Makumba code itself). <a
 href="#links_jikes" class="simplelink">Jikes</a> is
fully interchangeable with Java's normal javac compiler, but it's
faster. Only Jikes 1.18 works with Jasper 2 due to the UTF character
coding.<br>
    </li>
  </ul>
  <li><a href="#links_jdbc" class="simplelink">JDBC</a>: to connect to
databases. Makumba hides a lot of its
details. <a href="#links_jdbc" class="simplelink">JDBC</a>'s original
goal (version 1) was to be able to connect to
a database at all (i.e. try to support as many as possible, not
necessarily in an uniform manner). Database neutrality is more
important for JDBC 2 and 3. These versions also provide features that
may speed up Makumba internals.</li>
  <li>DB engines. In general transparent for the user, as part of DB
neutrality<br>
  </li>
  <ul>
    <li><a href="#links_mysql" class="simplelink">MySQL</a> is the main
DB engine supported by Makumba. We went from
version 3.23 to version 4.0, then we started using <a
 href="#links_innodb" class="simplelink">InnoDB</a> tables
instead of <a href="#links_myisam" class="simplelink">MyISAM</a>
tables. <a href="#links_maxdb" class="simplelink">MaxDB</a> tables
seem also to be interesting for
some fatures. <a href="#links_mysql" class="simplelink">MySQL</a> 4
(4.1?) brings interesting features like
subqueries, multi-table updates. <br>
    </li>
    <li>other DB engines that Makumba was tested with: <a
 href="#links_informix" class="simplelink">Informix</a>, <a
 href="#links_db2" class="simplelink">DB2</a>, <a
 href="#links_cloudscape" class="simplelink">Cloudscape</a>
(recently open-sourced by IBM), partly <a href="#links_odbcjet"
 class="simplelink">ODBCJet</a> on windows<br>
    </li>
    <li><a href="#links_mysqlConnectorJ" class="simplelink">mysql-connectorJ</a>,
the JDBC driver used by Makumba, presently
used version is 3.0.7, which is compatible with JDBC 3.0, there are
more advanced versions of it (3.0.14, 3.1), supporting pretty recent
JDBC features.<br>
    </li>
  </ul>
  <li><a href="#links_ant" class="simplelink">Ant</a>: used to build
and publish Makumba. Mostly transparent for
the user as far as Makumba is concerned (Ant is also used in karamba,
but that's another story). We went from Ant 1.3 to 1.6, increasingly
using its new features</li>
</ul>
<h2>Links</h2>
<h3>Approaches</h3>
<ul>
  <li><a name="links_cms"></a><a
 href="http://en.wikipedia.org/wiki/Content_management_system"
 target="_blank">CMS</a>: content management system</li>
  <li><a name="links_mvc"></a><a
 href="http://heim.ifi.uio.no/%7Etrygver/themes/mvc/mvc-index.html"
 target="_blank">MVC</a>: model-view-controller</li>
</ul>
<h3>Standards and standard candidates</h3>
<ul>
  <li><a name="links_sql"></a><a href="http://sqlzoo.net/"
 target="_blank">SQL</a></li>
  <li><a name="links_html"></a><a href="http://www.w3.org/MarkUp/"
 target="_blank">HTML</a></li>
  <li><a name="links_http"></a><a
 href="http://www.w3.org/Protocols/rfc2616/rfc2616.html" target="_blank">http</a></li>
  <br>
  <li><a name="links_odmg"></a><a href="http://www.odmg.org"
 target="_blank">ODMG</a> (Object Database Management Group) defined <a
 name="links_oql"></a><a href="http://www.odmg.org" target="_blank">OQL</a></li>
  <br>
  <li><a name="links_java"></a><a href="http://java.sun.com/"
 target="_blank">Java</a></li>
  <li><a name="links_servlet"></a><a
 href="http://java.sun.com/products/servlet/" target="_blank">Java
servlets</a>
    <ul>
      <li><a name="links_jsp"></a><a
 href="http://java.sun.com/products/jsp/" target="_blank">JSP</a>: Java
Server Pages
        <ul>
          <li><a name="links_jsp2.0"></a><a
 href="http://java.sun.com/developer/technicalArticles/javaserverpages/JSP20/"
 target="_blank">JSP 2.0</a></li>
          <li><a name="links_jstl"></a><a
 href="http://java.sun.com/products/jsp/jstl/" target="_blank">JSTL</a>:
the standard tag library</li>
          <li><a name="links_jsf"></a><a
 href="http://java.sun.com/j2ee/javaserverfaces/index.jsp"
 target="_blank">JSF</a>: Java Server Faces</li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a name="links_jdbc"></a><a
 href="http://java.sun.com/products/jdbc/download.html" target="_blank">JDBC</a></li>
  <li><a name="links_jdbcConnector"></a><a
 href="http://java.sun.com/developer/earlyAccess/jdbc/index.html"
 target="_blank">JDBC Connector</a></li>
  <li><a name="links_ejb"></a><a
 href="http://java.sun.com/products/ejb/" target="_blank">EJB</a>:
Enterprise Java Beans</li>
  <li><a name="links_jdo"></a><a
 href="http://java.sun.com/products/jdo/" target="_blank">JDO</a>: Java
Data Objects</li>
  <li><a name="links_struts"></a><a href="http://struts.apache.org/"
 target="_blank">Struts</a> proposes an MVC standard over servlets</li>
  <li><a name="links_jsai"></a><a href="http://oss.ipov.org/jsai/"
 target="_blank">jSai</a> proposes a critique of servlet authentication</li>
</ul>
<h3>Tools</h3>
<ul>
  <li><a name="links_eclipse"></a><a href="http://www.eclipse.org/"
 target="_blank">Eclipse</a>: a popular and flexible IDE</li>
  <li><a name="links_cactus"></a><a
 href="http://jakarta.apache.org/cactus/" target="_blank">Cactus</a>:
good for automatic testing of servlets/JSP/tag libraries</li>
  <li><a name="links_junit"></a><a href="http://www.junit.org/"
 target="_blank">Junit</a>: automatic testing</li>
  <li><a name="links_phpnuke"></a><a href="http://www.PHPNuke.org/"
 target="_blank">PHPNuke</a>, a CMS</li>
  <li><a name="links_tomcat"></a><a
 href="http://jakarta.apache.org/tomcat/" target="_blank">Tomcat</a>
implements servlet and JSP</li>
  <li><a name="links_jasper"></a><a
 href="http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jasper-howto.html"
 target="_blank">Jasper</a>, a JSP compiler in Tomcat</li>
  <li><a name="links_ant"></a><a href="http://ant.apache.org/"
 target="_blank">Ant</a>: a make-like tool in Java</li>
  <li><a name="links_jikes"></a><a
 href="http://www-124.ibm.com/developerworks/oss/jikes/" target="_blank">Jikes</a>:
fast Java compiler</li>
  <li><a name="links_antlr"></a><a href="http://www.antlr.org/"
 target="_blank">ANTLR</a>: parser generator for Java</li>
  <li>Database engines (SQL implementations)
    <ul>
      <li><a name="links_cloudscape"></a><a
 href="http://www-306.ibm.com/software/data/cloudscape/" target="_blank">Cloudscape</a></li>
      <li><a name="links_informix"></a><a
 href="http://www-306.ibm.com/software/data/informix/" target="_blank">Informix</a></li>
      <li><a name="links_odbcjet"></a><a
 href="http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/jetintro.mspx"
 target="_blank">ODBCJet</a></li>
      <li><a name="links_db2"></a><a
 href="http://www-306.ibm.com/software/data/db2/" target="_blank">DB2</a></li>
      <li><a name="links_mysql"></a><a href="http://dev.mysql.com/doc/"
 target="_blank">MySQL</a>, table formats:
        <ul>
          <li><a name="links_myisam"></a><a
 href="http://dev.mysql.com/doc/mysql/en/MyISAM.html" target="_blank">MyISAM</a></li>
          <li><a name="links_innodb"></a><a
 href="http://www.innodb.com/index.php" target="_blank">InnoDB</a></li>
          <li><a name="links_maxdb"></a><a
 href="http://www.mysql.com/products/maxdb/" target="_blank">MaxDB</a></li>
        </ul>
      </li>
      <li><a name="links_mysqlConnectorJ"></a><a
 href="http://www.mysql.com/products/connector/j/">Mysql Connector/J</a>
      </li>
    </ul>
  </li>
</ul>
</body>
</html>
